<?xml version="1.0"?>
<atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns:html="http://www.w3.org/1999/xhtml">
  <atom:id>http://bill.welliver.org/atom/smartos/poste.io upgrade</atom:id>
  <atom:title type="text">electronic.alchemy :: poste.io upgrade</atom:title>
  <atom:updated>2026-05-01T04:42:54-04:00</atom:updated>
  <atom:link href="http://bill.welliver.org/atom/smartos/poste.io upgrade" type="application/atom+xml"></atom:link>
  <atom:link href="http://bill.welliver.org/space/smartos/poste.io upgrade" type="text/html"></atom:link>
  <atom:link href="http://bill.welliver.org/rss/smartos/poste.io upgrade" type="application/rss+xml"></atom:link>
  <atom:generator uri="http://modules.gotpike.org/blahblah/Public.Syndication.ATOM" version="0.1">Public.Syndication.ATOM (Pike v8.0 release 702)</atom:generator>
  <atom:icon>http://bill.welliver.org/favicon.ico</atom:icon>
  <atom:logo>http://bill.welliver.org/static/images/alchemy.gif</atom:logo>
  <atom:subtitle type="xhtml"><html:div xmlns:html="http://www.w3.org/1999/xhtml"><html:i class="ital">Note:</html:i> Verified 3/10/2020<html:p class="paragraph"/>
Updating an LX zone from an updated docker image is pretty simple; if you want to preserve data you'll need to do so before-hand, or have pre-configured your zone to store things in a delegated dataset, which will be preserved across reprovisions. The only real trick is that the reprovision will remove the init script we added to mount the delegated dataset and lofs-mount any directories into the filesystem. So, we'll make sure we put that back in, after the reprovision but before the zone is started back up.<html:p class="paragraph"/>
This procedure also makes a backup of the zone just in case things go badly.<html:p class="paragraph"/>
<html:i class="ital">Note:</html:i> though this is presented in the form of a shell script, <html:b class="bold">DO NOT</html:b> run it as such, but rather consider each line individually. Otherwise you'll likely trash your zone.<html:p class="paragraph"/>
<html:div class="code"><html:pre><html:pre>&#xD;
<html:font color="brown"># import the new version of the image we want to run&#xD;
</html:font>imgadm <html:b><html:font color="darkblue">import</html:font></html:b> analogic/poste.io&#xD;
<html:font color="brown"># make note of the image uuid imported and set NEW_IMAGE to this value&#xD;
</html:font>UUID=91854c5c-a285-6522-9da8-e38a04116fd6&#xD;
NEW_IMAGE=some_uuid&#xD;
BACKUP_LOCATION=/zones/images/smtp-data.zfs&#xD;
SNAPSHOT_NAME=begin<html:p class="paragraph"/>
<html:font color="brown"># stop the zone and make a copy of the zfs delegated setup script  &#xD;
</html:font>vmadm stop ${UUID}&#xD;
cp /zones/${UUID}/root/etc/cont-init.d/01-init-zfs.sh /tmp<html:p class="paragraph"/>
<html:font color="brown"># this is not strictly necessary, but sometimes it's nice to have a backup.&#xD;
</html:font>echo <html:i><html:font color="darkred">"Backing up to $BACKUP_LOCATION..."</html:font></html:i>&#xD;
zfs snap zones/${UUID}/data@${SNAPSHOT_NAME}&#xD;
zfs send -Recv zones/${UUID}/data@begin &gt; $BACKUP_LOCATION<html:p class="paragraph"/>
echo <html:i><html:font color="darkred">"Reprovisioning..."</html:font></html:i>&#xD;
echo '{<html:i><html:font color="darkred">"image_uuid"</html:font></html:i>: <html:i><html:font color="darkred">"${NEW_IMAGE}"</html:font></html:i>}' | vmadm reprovision ${UUID}<html:p class="paragraph"/>
<html:font color="brown"># restore the zfs delegated dataset bootstrap and truncated directory setup &#xD;
</html:font><html:font color="brown"># scripts back into place. this is because they have to run the first time, every &#xD;
</html:font><html:font color="brown"># time and thus can't be installed from /data/_override (which is a feature that&#xD;
</html:font><html:font color="brown"># poste.io provides for making customizations to their image, and which is not&#xD;
</html:font><html:font color="brown"># a standard feature across docker images).&#xD;
</html:font><html:font color="brown">#&#xD;
</html:font><html:font color="brown"># alternatively, we could override the docker:cmd field and do something there&#xD;
</html:font><html:font color="brown"># or build a custom docker image.&#xD;
</html:font>vmadm stop ${UUID}&#xD;
cp /tmp/0*.sh /zones/${UUID}/root/etc/cont-init.d/<html:p class="paragraph"/>
<html:font color="brown">#If, for some reason the container starts up immediately after provision, the zfs init script won't work as &#xD;
</html:font><html:font color="brown">#the /data directory will be present and non-empty. If this happens, move it out of the way and restart.&#xD;
</html:font><html:font color="brown"># then, zlogin and verify that the /data directory has the delegated dataset (with the local and _override directories)&#xD;
</html:font>&#xD;
vmadm start ${UUID} &#xD;
<html:font color="brown"># to restart with ipf running we have to reboot.&#xD;
</html:font>vmadm reboot ${UUID}<html:p class="paragraph"/>
<html:font color="brown"># restoring the delegated dataset is not necessary when we use reprovision, but is &#xD;
</html:font><html:font color="brown"># kept as an example of how to do it.&#xD;
</html:font>zfs recv -F zones/${UUID}/data &lt; ${BACKUP_LOCATION}&#xD;
zfs rollback zones/${UUID}/data@${SNAPSHOT_NAME}&#xD;
zfs destroy zones/${UUID}/data@${SNAPSHOT_NAME}<html:p class="paragraph"/>
rm ${BACKUP_LOCATION}&#xD;
</html:pre></html:pre></html:div>
</html:div></atom:subtitle>
</atom:feed>
